[Core] Reject path traversal via embedded ".." segments in path_in_repo - #4884

Summary

_validate_path_in_repo() (used by every CommitOperationAdd/Copy/Delete, so
upload_file, upload_folder, create_commit, delete_file, delete_folder, ...)
only rejects a .. segment when it's the first path component:

if path_in_repo == "." or path_in_repo == ".." or path_in_repo.startswith("../"):
    raise ValueError(...)

A .. later in the path still escapes the repo root once resolved, and slips through
unchanged:

>>> from huggingface_hub._commit_api import _validate_path_in_repo
>>> _validate_path_in_repo("a/../../etc/passwd")
'a/../../etc/passwd'   # not rejected, even though it resolves outside the repo root
>>> _validate_path_in_repo("a/b/../../../etc/passwd")
'a/b/../../../etc/passwd'   # same

This fixes it by walking the full path and tracking depth relative to the repo root,
raising as soon as it would go negative (net traversal above the root) — instead of
only checking the very first component. A .. that resolves back into the repo
without escaping (e.g. "a/../file.txt") is still allowed, matching current behavior.

I don't know how the server itself handles a raw .. in a commit path, so I can't say
whether this is exploitable end-to-end today — this closes a gap in the client-side
guard either way, and the function's own comment says its purpose is exactly this
("prevent a server-side issue").

Test plan

Added cases to TestCommitOperationPathInRepo in tests/test_commit_api.py:
invalid_values gets "a/../../file.txt" and "a/b/../../../file.txt"; valid_values
gets "a/../file.txt" and "a/b/../../c/file.txt" to confirm non-escaping .. is
still allowed unchanged.

$ python -m pytest tests/test_commit_api.py tests/test_utils_paths.py -q
28 passed in 0.07s

ruff check/ruff format/ty check clean on the changed files.

Found this by reading _commit_api.py and testing _validate_path_in_repo directly
with a few traversal patterns, not from a reported issue.